Що таке git push та як його використовувати

1 year ago by admin

Відправка змін до чистого репозиторію

Перед push треба зв'язати локальний та віддалений репозиторії. Робиться це за допомогою команди:

git remote add <repository_name> <link>

Замість repository_name потрібно дати ім'я віддаленому репозиторію. Далі в інструкції замість цього параметра ми використовуватимемо origin, оскільки найчастіше використовують це ім'я. Замість link — посилання на віддалений репозиторій, воно може виглядати по-різному, залежно від того, використовується ssh або https.

Надсилання змін

Перед push треба зафіксувати поточні зміни, тобто зробити git commit.

Далі для відправлення в терміналі пишемо:

git push origin <branch>

Замість branch – ім'я гілки, яку треба відправити. Найчастіше використовується master або main:

git push origin master

Таке щоразу писати надто громіздко, для цього придумали git push за замовчуванням. Для цього один раз набираємо попередню команду з прапором -u:

git push -u origin master

Після цього можна писати коротше, тому що git запам'ятав, що пушити треба на сервер origin гілку під ім'ям master:

git push

Таким чином, git дозволяє запушити гілку у віддалений репозиторій. Щоб через git додати гілку у віддалений репозиторій, треба запушити існуючу локальну гілку.

Додаткові опції публікації

Надсилання гілки на сервер у гілку з іншим ім'ям

Для того щоб зробити git push в іншу гілку, є спеціальний синтаксис, де після імені гілки через двокрапку пишеться ім'я віддаленої гілки:

git push origin branch:server_branch

де branch – ім'я локальної гілки, server_branch – ім'я віддаленої гілки на сервері.

Надсилання всіх гілок на сервер

git push origin --all

Після цього всі зафіксовані зміни у гілках вирушать у віддалений репозиторій.

Надсилання поточної гілки

Зручний спосіб відправити поточну гілку з тим самим ім'ям на сервері.

git push origin HEAD

HEAD свідчить про поточну гілку (current branch). Тим самим не потрібно запам'ятовувати ім'я гілки, на якій ви знаходитесь.

Примусова публікація (git push - force ...)

При надсиланні може статися помилка публікації:

To github.com:example/test.git
 ! [rejected] master -> master (fetch first)
error: не вдалося надіслати деякі посилання до «github.com:example/test.git»

Це так званий git push rejected, він означає, що push був відхилений.
Найправильніше — зробити те, що написано у підказці до помилки. Потрібно отримати та смержити зміни, потім знову відправити.

Ця помилка відбувається, тому що git перевіряє, що новий commit заснований на попередніх комітах. Поки ви вносили зміни, хтось міг запустити зміни того, над чим ви працювали. Тому git не може виконати автоматичне злиття, ваш commit був раніше і він не базується на оновлених коммітах у віддаленому репозиторії.

Прапором -force або скороченою його версією -f вимикається перевірка коммітів і за потреби виконується перезапис історії.

git push --force

Потрібно бути обережними з цією командою, оскільки вона стирає роботу інших людей. Ця команда виправдана лише зрідка, наприклад, якщо ви майже одразу внесли зміни комміту за допомогою git commit-amend і запушили до того, як хтось зробив git pull.

Примусова публікація з параметром (git push - force-with-lease ...)

Це безпечніший, але так само нерекомендований варіант варіант примусового пушингу. Він не перезапише роботу у віддаленій гілці, якщо до неї були додані комміти від інших людей.

git push --force-with-lease

Примусова публікація з цим параметром загрожує появою git push rejected в інших людей